@lelgenio I am afraid, without the #not-has-ancestor and #has-ancestor predicates, the injections will not work with the latest versions of the tree-sitter-blade (v0.9.0^)

Did you remove them because Helix does not support these predicates? I am fairly new to Helix myself and already hooked big time, but not sure about their tree-sitter support.

((text) @injection.content
    (#not-has-ancestor? @injection.content "envoy")
    (#set! injection.combined)
    (#set! injection.language php))

; could be bash or zsh
; or whatever tree-sitter grammar you have.
((text) @injection.content
    (#has-ancestor? @injection.content "envoy")
    (#set! injection.combined)
    (#set! injection.language bash))


((php_only) @injection.content
    (#set! injection.language php_only))
((parameter) @injection.content
    (#set! injection.language php_only))

Oh, you're right! @tasks don't work correctly. I wonder if there's an equivalent predicated to #has-ancestor in helix 🤔

#9513 (comment)

Oh I just saw the comment by @the-mikedavis

#has-ancestor? / #not-has-ancestor? is a predicate that only exists in nvim as far as I can tell. For now we can remove that line and always inject php

Just to add, Nova added support for this last year with v11 as well. It is quite handy for extremely unusual template grammars! We could maybe do a "feature request" for these?

However for time being, feel free to safely comment/remove this section as it is redundant :)

((text) @injection.content
    (#has-ancestor? @injection.content "envoy")
    (#set! injection.combined)
    (#set! injection.language bash))

Seems like #has-ancestor? is working towards recognizing arbitrary nesting tree-sitter/tree-sitter#981

It was introduced in neovim/neovim#23606 and scans from the currently captured node potentially up to the root. I don't think that's particularly expensive but I was imagining that when arbitrary nesting was supported upstream by tree-sitter itself (probably a new syntax in the queries) it would track heritage internally and eliminate the cost of scanning.

I will write up an issue for this when I get a chance but let's not block this PR on it since the design is up for debate

@the-mikedavis Absolutely, by all means! The bash injection and envoy is for a very specific and niche use case in blade and its existence or lack of would not do any harm :). In fact no parser out there, had ever had this feature or been able to parse shell correctly in the blade files due to their limitation/complexity. In all honesty, I was just trying to see how far I can push tree-sitter with this feature when I was writing the grammar for it haha (tree-sitter never fails to please!).
But yea, having that section removed or commented for now, before the merge, is very sensible. Just to avoid unintended behaviour, because in the injection.scm both bash and php were being injected to the same node.

And I am totally with you on that one, I wished 'tree-sitter' had some form of standardisation for the predicates...

I just updated the PR to no longer include the bash injection, by the way.